Subject: Capabilities Exchange Format Proposal Comments

From: [email-masked]
Date: Thu, 9 Jun 94 18:22:43 EDT

Capabilities RIGlet,

 Here are some comments to Wayne's "Proposal for the Format of DLSw Capabilities
Exchange".

>   Run-Time Capabilities Exchange
>   ------------------------------
>       Capabilities Exchange normally occurs at the
>       startup of the data link switch.  However,
>       Capabilities Exchange can also periodically occur
>       at run-time.  Run-time Capabilities Exchange can
>       only consist of the following control vectors:
>        1. Exclusivity CV,
>        2. MAC Address List CV, and
>        3. NetBIOS Name List CV.

How will this function? Will the "Run-time" exchanges replace all of the
information passed in the initial exchange or will it contain delta information?
Obviously if it is delta information then we must define whether it is being
added or removed from previous exchanges.

Should the SAP CV be added to this list?

>        +---------------------------------------------------------------+
>        |   DLSw Version (X'82') Control Vector                         |
>        |                                                               |
>        |       The DLSw Version control vector identifies the          |
>        |       particular version of the DLSw standard supported by    |
>        |       the sending Data Link Switch.  This control vector is   |
>        |       required.

This looks OK with me but I must object to the statement "X'1434' .. (not
used)". Seems that this would be a perfect vehicle for down-level Data
Link Switches, which only implement Capabilities Exchange, to announce
themselves to Standard Data Link Switches. Information such as, this partner
uses Enter/Exit Busy for Flow Control could be implied from this.

>       +---------------------------------------------------------------+
>       |   NetBIOS Support (X'85') Control Vector                      |
>       |                                                               |
>       | The NetBIOS Support control vector identifies support         |
>       | for the NetBIOS protocol by the sending Data Link             |
>       | Switch.  This control vector is optional.  If it is           |
>       | omitted in a DLSw Capabilities Exchange, then no              |
>       | NetBIOS support is assumed.                                   |

I'm a little confused about what this CV means. What happens if I support
NetBIOS but it is currently not configured? Should this CV be extended to
include that type of information or should the SAP CV list be checked for F0?

>        +--------------------------------------------------------------+
>        |   Loop Prevention Support (X'86') Control Vector             |
>        |                                                              |
>        |         The Loop Prevention Support control vector identifies|
>        |    support for the loop prevention algorithm as specified    |
>        |    in the Data Link Switching specification.  This control   |
>        |    vector is optional.  If it is omitted in a DLSw           |
>        |    Capabilities Exchange, then no Loop Prevention support    |
>        |    is assumed.                                               |

Discussions on the Loop Prevention RIGlet seem to indicate that this function
will not be included in the next RFC. Seems that the CV should be left out
until this work is completed.

>       +---------------------------------------------------------------+
>       |   TCP Sessions (X'87') Control Vector                         |
>       |                                                               |
>       |    The TCP Sessions control vector indicates the support      |
>       | of an alternate number of TCP sessions for the Data           |
>       | Link Switching traffic.  The base implementation of           |
>       | Data Link Switching supports two TCP sessions, one for        |
>       | each direction of data traffic.                               |

I have some concerns about this being included prior to defining how to handle
mismatches. If one side says it 'can be brought down to one' and the other says
it 'will remain at two', who wins? Seems like two needs to win every time. Also,
what is the procedure to drop down to one? If this isn't defined then it starts
to look like a 'vendor-specific' CV.

> A negative DLSw Capabilities Exchange Response has the following
> overall format:
>
>    +----+----+--------+--------+
>    | LL | ID | Offset | Reason |
>    +----+----+--------+--------+
>

Sounds good but I have a couple of questions: What actions should a Data Link
Switch take when it receives a negative response? Should it retry or just
report the error and not attempt another exchange? Do we need a mechanism to
ask the other Switch to not attempt another exchange? (useful in the event that
there is a mis-configuration in the network and a Switch is not allowed to
connect.)

Regards,
  Steve Petriccione

.-----------------------------------------------------------------------------
| Steve Petriccione: [email-masked]
| Data Link Switch Development
| International Business Machines Corp.
| Research Triangle Park, NC
'-----------------------------------------------------------------------------

---

From: Wayne Clark <[email-masked]>
Date: Sat, 25 Jun 94 17:35:32 PDT

Steve and other Capabilities folks -

    Hope you get this before Tuesday's meeting.  If not, we'll discuss it
    in more detail then.

    Responses below marked with "[Wayne]".

Wayne

>>   Run-Time Capabilities Exchange

 [Steve]
>added or removed from previous exchanges.

    [Wayne]
    We discussed this at AIW #4 as being a replacement operation.   I've
    enhanced the CapEx Format Proposal to reflect this fact.

 [Steve]
>Should the SAP CV be added to this list?

    [Wayne]
    We should discuss this at the AIW.  I'm not sure that the SAP CV warrants
    inclusion at run-time but I would like to hear your reasoning.

 [Steve]
>uses Enter/Exit Busy for Flow Control could be implied from this.

    [Wayne]
    Backrev implementations of DLSw (read: RFC1434) do not issue
    Capabilities Exchanges.  At first, I put this in on a lark but then
    realized that it was correct ... strict implementations of RFC1434
    do not issue CapEx.

 [Steve]
>include that type of information or should the SAP CV list be checked for F0?

    [Wayne]
    This sounds as if you're interested in providing an implementation of
    DLSw that supports NetBIOS but allows you to selectively configure
    its support per DLSw-DLSw router pair.  If this is the case, then
    this is how this CV would be used:

	if NetBIOS is supported in an implementation of DLSw, then
	    if NetBIOS is configured for this DLSw-DLSw pair, then
		NetBIOS Support CV = "supported"
	    else
		NetBIOS Support CV = "not supported"
            endif
	else
	    NetBIOS Support CV = "not supported"
	endif

    If a DLSw-DLSw pair needs to change its support for NetBIOS, then the
    TCP connection has to be brought down and then brought back up with a
    CapEx reflecting the new values.

 [Steve]
>until this work is completed.

    [Wayne]
    I agree ... I'll take the Loop Prevention Support CV out for now.

 [Steve]
>to look like a 'vendor-specific' CV.

    [Wayne]
    You are right ... it wasn't very clear.  We never really decided how to
    handle it.

    Here is a proposal (I'll also present this at the AIW).  Given the
    configuration:

    DLSw A						DLSw B
    +-----------+                                       +-----------+
    |      2067 |  -- Connect Out ------------------->  | 2065      |
    |           |                                       |           |
    |           |=======================================|           |
    |           |                                       |           |
    |      2065 |  <- Connect In --------------------   | 2067      |
    +-----------+					+-----------+

	if TCP Sessions CV values agree, then
	    use the number of sessions in CapEx
	    if the number of sessions is one, then
		if IP address of this DLSw > IP address of partner DLSw, then
		    drop the TCP session for port 2065
		else
		    do nothing: other DLSw will drop the extra TCP session 
		endif
	    else
		do nothing: if no. sessions is 2, we're done; if no. sessions
		is > 2, then extra sessions will be brought up later
	    endif
	else
	    no. TCP sessions disagree: use 2 TCP sessions
	endif

>> A negative DLSw Capabilities Exchange Response has the following

 [Steve]
>there is a mis-configuration in the network and a Switch is not allowed to

    [Wayne]
    This is (closed) Issue 21 from the Capabilities Exchange Issue List:

    21	Receiver of -RSP(CapEx) drops TCP connection		closed - aiw4

    Thanks for the input.  See you on Monday!

Wayne